home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d12
/
mflms101.arc
/
MFLMS.DOC
< prev
next >
Wrap
Text File
|
1989-11-25
|
45KB
|
1,268 lines
==============================
= MICROFIRM FUNCTION LIBRARY =
= for Microsoft C & Quick C =
= - by - =
= Bob Stout =
==============================
Functions and Documentation Copyright 1988-89
by Robert B. Stout dba MicroFirm
Portions Copyright 1986-87 by Steven E. Margison
-- All Rights Reserved --
--------- TABLE OF CONTENTS ---------
Introduction ................................. 1
The Documentation ............................ 1
Installation ................................. 2
Linking ...................................... 3
Real Time Interrupt Handler .................. 4
Video Functions .............................. 5
A. Introduction .......................... 5
B. Initialization ........................ 5
C. De-Initialization ..................... 6
D. Cursor and Character Placement ........ 6
E. Writing Characters and Attributes ..... 7
F. Miscellaneous Operations .............. 7
G. Video Page Switching .................. 8
H. Reading from Video Memory ............. 9
Utilities .................................... 10
Rebuilding Libraries.......................... 13
"We Get Letters" ............................. 14
Shareware & Online Help ...................... 17
Warranty ..................................... 20
Registration Form ............................ --
MicroFirm Function Library for Microsoft C & Quick C
I. INTRODUCTION
The heart of the C language is its library. Each
compiler has its own library of functions, which is complete
only to the degree that the compiler author wishes to make it.
The Microsoft C compilers are excellent products, and come with
a very extensive function libraries which have all the usual
"standard" functions, plus many DOS functions as well. However,
the more functions a programmer has at his disposal, the shorter
the time from idea to complete program. That's where The
Microfirm Function Library comes in. With over 200 functions it
greatly enhances program development with Microsoft C & Quick C.
The MicroFirm Function Library has an entire set of
direct video functions originally written for the Turbo C
compiler, and modeled after similar functions supplied with the
Zortech and earlier Datalight C compilers. Even though many
compiler vendors now offer direct video access packages, the
MicroFirm Function Library's is an attractive alternative.
II. THE DOCUMENTATION
The documentation for the library is contained in the
file, MFL_FUNC.MAN, which describes each function. A companion
quick reference, MFL_QREF.DOC, is also provided which briefly
lists the prototypes and functional descriptions for all
lirary functions. Additional documentation includes TKNOTES.DOC,
containing technical notes on the 1.01 release, README which
contains miscellaneous information along with changes from
previous versions, and CREDITS wherein the folks who helped make
this library a reality are given proper recognition.
MicroFirm Function Library for Microsoft C & Quick C Page 1
III. INSTALLATION
The MicroFirm Function Library is distributed as five library
files for each type of memory model. (Only the full registration
with source has all five libraries. The filenames are:
MFLMSS.LIB Small Memory Model
MFLMSC.LIB Compact Memory Model
MFLMSM.LIB Medium Memory Model
MFLMSH.LIB Huge Memory Model
MFLMSL.LIB Large Memory Model
For the remainder of this manual the libraries will be referred
to as MFLMSx.LIB.
A typical hard disk installation of Microsoft C or Quick C will
consist of several directories, one of which will contain all
the "include" files (those with ".H" extensions) and one with
the library files (those with ".LIB" extensions). All files in
The MicroFirm Function Library" with an ".H" extension should be
placed in the directory with the other ".H" files. Similarly,
all MicroFirm Function Library files with a ".LIB" extension
should be placed with the other ".LIB" files. The documentation
and source files from The MicroFirm Function Library" do not
need to be on the hard disk, as they will only be used to print
the documentation or modify the function source. They are not
used in the creation of a program. The executable utilities
(*.EXE) files supplied with The MicroFirm Function Library may
be optionally placed in any directory specified in your PATH
environment. These programs are all examples of function usage
and C programming, and do not directly relate to program
development. However, they are useful and should be placed on
your system for access.
The files in The MicroFirm Function Library with an extension of
".BAT", ".MFL" or ".MAC" are required only for re-assembling the
assembly language modules from this library. They do not need
to be placed on your hard disk unless you plan to re-assemble
any ".ASM" source code files.
MicroFirm Function Library for Microsoft C & Quick C Page 2
IV. LINKING
The MFLMSx.LIB library must be linked with any other
libraries whenever a function is used in your program. Some
programs may not use MFLMSx.LIB functions, and therefore the
linking of the library may be eliminated to save time. In
addition, if you have other third party libraries, be sure to
include them after MFLMSx.LIB.
There are several methods to invoke the MFLMSx.LIBs when
linking under Microsoft C or Quick C. Refer to your compiler
manual or on-line help for information on using the libraries
either from the command line (using CL.EXE or QCL.EXE) or within
the QC programming environment.
MS LINK.EXE can link files with case-sensitivity on or
off. With case off, the symbols foobar() and FOOBAR() would be
considered the same. With case on, they would be different.
C is inherently a case sensitive language so, though it is
really bad form to name functions or variables with identical
names but varying case, The MicroFirm Function Libraries are all
compiled and/or assembled with case-sensitivity enabled.
MicroFirm Function Library for Microsoft C & Quick C Page 3
V. REAL TIME INTERRUPT HANDLER
A special feature of The MicroFirm Function Library is the
"ticker" interrupt handler function. This function provides the
programmer with the ability to install a special routine to
intercept DOS interrupt 1CH. ticker() is a pre-built handler
which allows the user to perform operations relative to the
system's clock. A special variable may be loaded with a value
and then tested at intervals. When the variable has hit zero, a
specific amount of time has passed. The variable counts 18.2
times per second, and is installed on INT 1CH.
The usage of this interrupt handler forces some hard
rules on the programmer. Since this is an interrupt routine
which is called asynchronously to your program, it ABSOLUTELY
MUST be un-installed BEFORE your program exits to DOS. To do
otherwise will invariably cause the next program run to crash
the system, since the 1CH interrupt will then be invoked to a
section of code in the new program which is NOT intended to be
run from int 1CH. Therefore, it is imperative to control exits
from your program when using the ticker. This means that your
program should exit from only one place, which calls
removetick() before performing the actual exit. With good
program design, this is easy to accomplish. (Watch out for my
error(), cant(), badext(), and eraok() functions, though, since
they will exit the program all by themselves!) What isn't so
obvious is the manner in which a program may exit beyond control
of the program itself. This is done if the user types a
control-break, or responds with (A)bort to a DOS critical error.
To avoid exiting the program under these circumstances, any
program which uses the ticker MUST ALSO use Turbo-C's ctrlbrk()
AND harderr() functions to trap and cleanly process a program
exit. The Turbo-C function "atexit()" can also be used to
insure that the ticker is removed upon ANY program exit, and is
probably the preferred means of accomplishing this. The
function removetick() would be registered with atexit() in order
to insure it is called upon exit.
One exception: if the program is a terminate and stay
resident (TSR) utility which needs interrupt 1CH to function,
then removetick() should NOT be invoked before using the
resident exit DOS command.
The ticker interrupt routine resolves time only to about
55 milliseconds. For timings with finer resolutions, the 8253
timer chip may be utilized for timings to microsecond
resolution. Refer to the documentation on the high resolution
timer function, uclock().
MicroFirm Function Library for Microsoft C & Quick C Page 4
VI. VIDEO FUNCTIONS
A. Introduction
The MicroFirm Function Library provides a complete facility for
direct writes and reads in video memory. Direct video memory,
dvid for short, provides the programmer with a means of creating
extremely fast screen displays, with full control over colors
and attributes. Virtually all good programs, commercial or
otherwise, make use of direct video access to create the rapid,
sparkling displays that attract users. There is one gotcha,
though. Direct video access works only on systems which are
truly IBM compatible. Thankfully, this is almost every PC-type
system nowadays. However, there still may be the occasional
wierdo system which places video memory at an oddball address.
With these systems, the direct video access package in this
library will fail. However, since there is a BIOS override, it
should still be possible to configure a program to operate using
rom-bios services for those cases.
Using dvid is very simple, but carries some extra
responsibility for the programmer, especially if the program
being created is intended for public distribution. Some things
to consider are:
* provision for forcing black & white on a CGA, in
case the user has only a monochrome monitor
* provision for changing the default colors. (Just
because YOU like magenta text on a blue background
doesn't mean that everybody else does!)
* provision for forcing bios routines in case the user
has an oddball video system.
* sensing a monochrome adapter card (MDA) and altering
the program accordingly; i.e., no video page
switching, and an underline attribute.
Of course, you can always specify that your program
requires a CGA only, or an MDA only, but it is better to have
the ability to work with both if possible. For the remainder of
this discussion it may be handy to have a printout of DUMP.C
(one of the supplied utilities) for reference. This program
does not take into consideration user configuration, since it is
supplied in source form. Don't like the colors? Edit the
source and re-compile it! As a matter of fact, this program
serves as a good "test bed" for the dvid functions. Many
modifications are possible to demonstrate the use of the dvid
functions.
B. Initialization
Before the dvid functions can be used, the dvid_init()
function must be invoked. This function investigates the
system's resources and sets the base video address, number of
rows, and columns, into its private memory area. This
information is critical to proper dvid operation. Using any of
the functions before invoking dvid_init() will probably cause
problems on MONO boards, and definitely cause trouble with CGA
or EGA boards. If the initialization procedure encounters any
MicroFirm Function Library for Microsoft C & Quick C Page 5
type of video information which it cannot understand, then a
flag is set and all video access through the system will then be
done through rom-bios video services, instead of directly to
memory. Generally, the only effect of this will be to make
screen writing noticably slower, but still not as slow as normal
text writing through DOS. In addition, it will NOT be possible
to display one CGA video page and write to a different one.
However, the occasions when this would occur should be very
rare. There are ways to insure that EGA cards will behave as
MONO or CGA cards. By using the vmode() function you can set
the video mode desired before calling dvid_init(). Then,
dvid_init() should obtain the correct mode from an EGA emulating
a CGA, and avoid setting the bios flag.
dvid_init() has no effect if called more than once,
since a check is made on an initialization flag. Therefore, it
is not possible to change video modes and then recall
dvid_init(). In order for dvid_init() to re-initialize the
video system, dvid_done() must first be called to
"de-initialize" the video system and restore all internal
defaults.
C. De-Initialization
There is really no overwhelming need to call the
dvid_done() function, unless you just happen to be a "neat-nik".
dvid_done() updates the screen cursor position and restores the
cursor shape to what it was when dvid_init() was invoked. In
addition, it will restore all of the dvid function internal
parameters to their default values and make possible the recall
of dvid_init(). Normally, dvid_done() would be called just
prior to exiting the program.
D. Cursor and Character Placement
The dvid system maintains two sets of row/column
parameters. The first indicates where the NEXT character will
be written in the video memory. The second stores the position
of the REAL onscreen cursor. Since rom-bios routines are used
to change the location of the onscreen cursor, it is not
efficient to continually update the onscreen cursor for all dvid
write operations. The dvid_flush() function is provided to
perform that operation. I will refer to the "internal" cursor,
and the "screen" cursor in the following discussions. The
internal cursor is the position which will be next written. The
screen cursor is the actual onscreen cursor, whether it is
actually visible or not.
All of the dvid functions which take a row/col value and
a character or string argument, such as dvid_say() or
dvid_char_at(), will call dvid_flush() at the end of the
operation to update the screen cursor to the internal cursor
position. However, the lower level functions such as
dvid_putchr() will NOT automatically update the screen cursor to
the internal cursor. Normally, dvid_flush() is only called
after a block of text is written and it is necessary for
MicroFirm Function Library for Microsoft C & Quick C Page 6
cosmetic reasons to show where the cursor "really" is. Since it
uses rom-bios functions, using dvid_flush() sparingly will
increase overall screen display speed.
The function dvid_move() is used to set the internal
cursor position to a new location. Note that the screen cursor
is NOT affected by a call to dvid_move().
E. Writing Characters and Attributes
When writing with normal DOS functions to the standard
output channel, no concern is ever made about screen attributes
or colors. However, when writing directly to video memory, it
is actually necessary to write out two bytes for each character;
one is the character, the second is the attribute. The dvid
system saves an attribute internally which is automatically
written each time a character is written to video memory. At
initialization, the attribute defaults to normal white on black.
The dvid_attrib() function is used to change the default
attribute to any valid attribute for the video mode in use.
Refer to the file screen.h for a mnemonic list of screen colors
and attributes.
The primary function for placing characters to the
screen is dvid_putchr(), although in practice dvid_say() and
dvid_char_at() may actually be more useful. dvid_putchr() will
properly place all 256 possible character values with these
exceptions:
07H Sounds Bell
08H Backspaces unless internal cursor is in column 0
09H moves internal cursor right to next mod-8 column
(horizontal TAB)
0AH moves internal cursor down 1 row
(linefeed)
If internal cursor is already at bottom of screen,
screen scrolls up by 1 line
0DH moves internal cursor to column 0 of current line
(carriage return)
0BH moves internal cursor up one line, unless cursor is
already on line 0
(vertical TAB)
7FH (delete) is ignored
All other characters below 20H (space) are ignored
A new feature of version 1.50 allows all control characters to
be displayed directly. The dvid_raw() function controls
handling of these special characters. Called with a TRUE
argument, all dvid functions will display control characters
literally. Called with a FALSE argument restores the operation
listed above.
F. Miscellaneous Operations
There are a number of other functions to aid in screen
management. As noted above, a screen attribute can be set and
altered at will. The function dvid_getattr() will return the
value of the current attribute in use, and the current video
MicroFirm Function Library for Microsoft C & Quick C Page 7
page selected for writing. In order to erase characters,
dvid_e2eol() is provided to erase from cursor to end of line,
and dvid_e2eos() erases from cursor to end of screen. In each
case, the cursor position used is the internal cursor, and the
screen cursor is updated automatically to match. To clear the
entire screen, do:
dvid_move(0,0); /* cursor to upper left corner */
dvid_e2eos(); /* erase from 0,0 to end of screen */
- or -
dvid_cls(); /* performs a direct screen clear &
home cursor */
The CGA video card must be written to (or read from)
only at certain times to prevent video "snow". Monochrome cards
do not have this problem. Normally, all dvid functions will
automatically synchronize with the CGA card to suppress snow.
However, it is possible to turn synchronization on and off with
the dvid_sync() function. An argument of 0 (FALSE) will turn
sync off, and a non-zero argument (TRUE) will turn sync on
(default condition). Why turn sync off? Well, some EGA cards
do not produce snow, so that sync is not needed when they are
used in CGA mode. Or, in some cases, the extra speed of writing
without sync may be preferable to a little video snow. The
function is provided so that full flexibility is possible.
dvid_scroll() is a function which uses rom-bios features
to scroll a region of the current screen up or down. Refer to
the detailed description for this function for an explanation of
its arguments.
If dvid_init() cannot properly initialize itself, it
sets an internal flag which then forces the dvid functions to
use only rom-bios video functions. This slows down video
access, but provides compatibility for oddball video cards. As
a backup to this, the dvid_bios() function can be called AFTER
dvid_init() to force the use of bios. Note that once selected,
there is no way to turn bios off without calling dvid_done() and
re-initializing the entire video system.
It is possible to change the attributes on a section of
the screen by using the dvid_chgattrib(). Parameters are the
starting row and column, the ending row and column, and new
attribute. If using a CGA card, synchronization will be
performed unless it has been turned off with dvid_sync(FALSE).
Note that rom-bios functions will NOT be used with this
function. Therefore, this function MAY fail if used on a card
which does not map video into the "normal" areas, even though
the use-bios flag has been set.
G. Video Page Switching
dvid_setpage() may be used to control the video page in
use, if a CGA card is being used. (MDA card video paging is not
supported.) If a CGA card is used in 80 column mode, there are 4
video pages in memory, numbered 0-3. For 40 column mode, there
are 8 pages, 0-7. dvid_setpage() takes two arguments. The first
MicroFirm Function Library for Microsoft C & Quick C Page 8
is the video page to select for all write/read operations. The
second argument is FALSE to select the video page for write/read
only, and TRUE to also select for display. Using this function
judiciously it is possible to write to a video page not
currently being displayed, and then switch to that page
instantly. This can be done as follows:
dvid_setpage(0, TRUE); /* select page 0 for write and display */
dvid_setpage(1, FALSE); /* select page 1 for writing, but do
not change currently displayed page */
dvid_say(10, 5, "Hello World"); /* write to page 1 */
dvid_setpage(1, TRUE); /* make page 1 display now */
One caution is necessary when switching video pages. It is
HIGHLY recommended that you insure a full return to page 0
before exiting the program. Leaving the system on a different
page often prevents subsequent programs from working properly.
H. Reading from Video Memory
Although few programs will ever need to read what is on
the screen, there is support in The Microfirm Function Library to
accomplish this. The dvid_getchr() function will read the
character and video attribute at a specified row/column position.
Synchronization will be active or inactive as for writing, and
the page selected for writing will be the page used for reading.
MicroFirm Function Library for Microsoft C & Quick C Page 9
VII. THE UTILITIES
The MicroFirm Function Library comes with several utilities,
including the C source code. Nothing earth shaking here, just
some convenient programs to make life a little easier. All the
programs use functions from The MicroFirm Function Library, and
can serve as an example of proper usage. Here is a short
description of each utility:
INPATH
This utility searches for an EXECUTABLE program in the
current path. Typing INPATH at the DOS prompt will display the
version number and a short usage message. To use, type:
inpath <filename>
where filename is the basename portion of the executable file to
find. Note that an extension can be specified, but it is
ignored. INPATH will first look for the file in the current
directory, and then look in the PATH environment variable (if it
is present) in the order specified. For each directory, INPATH
first tries to locate a .COM file, then a .EXE file, then a .BAT
file, since that is the order in which DOS searches for files.
On the first match, INPATH reports the directory and full
filename of the program and then exits. If none are found, that
fact is reported.
TEXTCOMP
This is a quick Text Compare program to compare two
ASCII files. Typing TEXTCOMP at the DOS prompt will display the
version number and a short usage message. To use, type:
textcomp file1 file2
where file1 and file2 are the two files to compare. If the
files are identical, no more messages will appear. Otherwise,
the program will report any lines which are different with the
filename, line number, and a printout of the actual line. If
one file ends before the other, the program reports which file
terminated first.
MicroFirm Function Library for Microsoft C & Quick C Page 10
WC
WC counts words, lines, characters, and checksums one or
more files. Typing WC at the DOS prompt will display the
version number and a short usage message. To use, type:
wc filename [-wcls]
where filename is the name of the file to act upon. With no
options, the program will report words, characters, lines, and a
checksum, which is a simple binary addition of all character
values. No, it ain't a CRC, but it is a quick check to see if
it the same as another file under the same name. The options
[wcls] tell the program to report ONLY the items specified:
-w report only words
-l report only lines
-c report only characters
-s report only checksum
Note that giving all options is the same as giving no options.
Since words, lines, and characters are meaningless in a non-text
file, the program examines the filename extension to determine
if the file is a binary or text file. This isn't a perfect
method, but it is good enough. If the file extension is .COM,
.EXE, .OBJ, .REL, .PFS, .LIB, or .BIN, then only the checksum is
reported, overriding all other options. The program supports
wildcards in the filename, as well as drives and directories.
GTOD
This utility will report the current system time and
date in a variety of formats. GTOD may be invoked with or
without options. Options may be preceded by dash, fraction bar,
or nothing at all.
gtod <options>
-d report only date
-t report only time
-e report date in European format (DD/MM/YY)
-s report seconds, if time reporting enabled
-r reverse reporting order, with time first and date second
-l spell out month in long format
-n if option -l, then add name of weekday
-m report time in 24 hour (military) format
-v report version number
-? usage message and exit
no options defaults to -dt
Output may be redirected to a file or another device, except for
MicroFirm Function Library for Microsoft C & Quick C Page 11
error messages.
GTOD demonstrates the system clock interface, as well as
error(), monthis(), wkdayname(), i_dstr(), and weekday().
Program idea: allow calculation for other time zones.
DUMP
This program will dump any file to the screen in a
"debugging" display format, in color if it senses a CGA card
installed, or with blinks and highlights if a mono card is
sensed. The direct video access functions are used. It will
optionally highlight any selected byte whenever it is found, and
it displays only 20 lines at a time and waits for a keypress to
continue. Invoke the program as follows:
dump filename -soffset -hbyte -r
where filename is the file to dump, offset is the hex offset
value in which to index into the file before dumping (defaults
is 0000), and byte is the hex value to highlight (default is no
highlight). The parameters may be in any order. The -r option
is used to modify the "ascii" display in the rightmost columns.
When not used, any non-printable ASCII character is displayed as
a period. When used, all characters are displayed.
DUMP demonstrates the use of getkey(), stuff(), error(), plus
the direct video functions of this library, and the use of color
attributes.
MicroFirm Function Library for Microsoft C & Quick C Page 12
VIII. REBUILDING LIBRARIES
If you want to remake the entire library from the source
files, the procedure has been automated with a batch file and
a make file.
You will need, besides Microsoft C or Quick C of course,
Microsoft's MASM, NMAKE, and LIB. The batch file to rebuild any
library module or the entire library is BUILD.BAT and is self-
prompting.
To remake the libraries, you will most likely need to be
on a hard disk. A dual floppy system can't handle it all in one
chunk. If you have a floppy system, you will have to remake the
library in pieces, bringing in only a few source files at a
time. On a hard drive, make a subdirectory and copy into it all
source and header files, plus the BUILD.BAT and MAKEFILE
files from The MicroFirm Function Library's distribution disk.
Then, making sure that CL.EXE or QCL.EXE, MASM.EXE,
NMAKE.EXE, and LIB.EXE are in your current PATH, simply execute
"BUILD.BAT LIBS m c" where "m" is the memory model and "c" is an
optional switch ("Q") when used with Quick C. They will
recompile and reassemble each source files and then create a new
library file from the OBJ files. The rebuilt library file will
be placed into the directory specified by the "LIB" environment
variable. Afterwards, you may delete everything in the working
directory. BUILD.BAT and MAKEFILE are only supplied with full
source registration.
To replace only selected functions in the library, as
after a modification, use "BUILD xxx.OBJ m c" where "xxx" is the
module name without its .C or .ASM extension and "m" and "c" are
as described above. Be sure to update all five libraries.
MicroFirm Function Library for Microsoft C & Quick C Page 13
X. SHAREWARE AND ONLINE HELP
Shareware is "try-before-you-buy" software, reasonably
priced and user-supported. This simply means that you can get
trial copies of shareware from anyone who has a copy, or often
from bulletin board systems. If you use and like the program,
then the author asks that you register (purchase) the program
for an amount usually much smaller than an equivalent commercial
program. By registering you will often also receive notice of
available upgrades or supplemental programs. Keep in mind that
the purchase of a program from a public domain distributor or
payment to an online service (such as CompuServe) does NOT
constitute registration of the program since the producer of the
program does NOT receive one penny of that payment. Shareware
is NOT public domain software, and continued use of a program
carries with it the OBLIGATION to purchase the program. The
free distribution method is intended only as a means of
obtaining a copy to evaluate before purchasing.
The MicroFirm Function Library is a shareware program.
If you use it, please complete the order form enclosed with the
distribution. You will be placed on a mailing list for any
future upgrade notices, and will be registered as a user of this
product. You will also receive a set of diskettes with the
latest version, plus the H, C, M, and L model libraries, and all
source code. Online help is available via BIX (bob.stout)
to registered users ONLY.
Help is also available by mail. I will try to answer
all letters within 48 hours. Non-registered users must include
a SASE for a reply. The degree of help offered to
non-registered users is purely discretionary. No phone calls,
please. (Users outside the U.S. cannot, of course, send a SASE.
I will excuse you from this requirement.)
The Small model library, documentation files, and
utilities of The MicroFirm Function Library may be freely
exchanged or given away. (This is all the files on Disk #1 of a
distribution set.) However, they may not be included or
"bundled" with any software which is sold or is a commercial
product without prior permission. No charge may be made for
copying or transferring the files, except that PC Users groups
and PD/Shareware distributors (such as PC-SIG, or Nelson Ford's
Public Software Library) may charge a nominal fee not to exceed
$6.00 ($12.00 outside the U.S.). (Please request a complementary
copy of the latest release rather than use a copy from another
user. This insures that you have the most accurate copy, and
that you will be on my list for future updates.)
The MicroFirm Function Library and its documentation may
not be transferred nor exchanged in any modified form. If you
really want to "hack" the source or the documentation, by all
means do so; but don't give the hacked version to anyone else. I
cannot be expected to help others use this product if it is not
the same as it was when distributed. Under no circumstances may
the copyright notices be altered or removed from the product or
this documentation.
MicroFirm Function Library for Microsoft C & Quick C Page 17
If you decide not to use this product, then just erase
it or pass it on to someone else. If you do use it, please
honor your obligation and send in your registration.
Inexpensive shareware cannot continue to exist if those who use
it treat it as a gift, rather than as a product for which the
author must receive payment. Shareware used regularly without
payment is piracy just as much as illegally copying "Lotus" or
any other commercial product. Ignore the claims by some people
that shareware, because of its unique distribution method,
carries no obligation to the regular user. These claims are
false, and discourage many good programs from remaining as
shareware.
MicroFirm Function Library for Microsoft C & Quick C Page 18
XI. WARRANTY and CREDITS
Oh, this shouldn't be necessary among friends and
gentlemen, but it's really the lawyers who run the world and
they say we gotta do this:
** The MicroFirm Function Library functions and all
documentation are copyright 1988-89 by Robert B. Stout
and/or copyright 1986, 1987 by Steven E. Margison.
** These functions and documentation are provided "as
is" without warranty of any kind, either expressed or
implied, including but not limited to the implied
warranties of merchantability and fitness for a
particular purpose.
** The user of these functions and documentation agree
to hold the author and/or distributor(s) of this
material harmless for any direct or consequential
damages resulting from its use. In other words,
"you're on your own!"
** IBM is a registered trademark of International
Business Machines Corporation.
** MS-DOS is a trademark of MicroSoft Corporation.
** Microsoft C and Quick C are registered trademarks
of Microsoft, Inc.
** Zortech C and Zortech C++ are registered trademarks
of Zortech, Inc.
** Turbo-C is a registered trademark of Borland
International, Inc.
** Other registered trademarks may be used herein and
are acknowledged.
MicroFirm Function Library for Microsoft C & Quick C Page 19
=======================================================================
SOFTWARE REGISTRATION FORM AND ORDER
=======================================================================
A separate form must be filled out for each product ordered or
registered. This form may be photocopied, printed out, or
edited to include all information and re-printed.
PRODUCT: -------- MicroFirm Microsoft LIBRARY VERSION 1.01 ------------
QUANTITY: Amount:
_____ Registration with Source code $25.00 ea $______
_____ Update from MFLZT or SMTC $10.00 ea $______
_____ Additional Zortech C version $10.00 ea $______
Shipping outside U.S. or Canada $ 3.00 $______
Surcharge for non-U.S. Funds $ 5.00 $______
TOTAL DUE $______
Source code is NOT SHAREWARE and is not to be transferred to other
users. Only the DOC files, header files, utilities,
and S library are released into shareware.
Corporations: Write with your requirements for a quote on
multiple copies or site licensing.
If you already have this library, where was it obtained?
[ ]BIX [ ]Friend [ ]Employer [ ]BBS:__________________
Version_____ Serial No._________
If updating from SMTC: Version_____ Serial No._________
Payment is by check[ ] or money order[ ] (Sorry - no COD or charges)
NAME _______________________________________________________
COMPANY ____________________________________________________
ADDRESS ____________________________________________________
CITY _______________________________________________________
STATE___________________________ ZIP _______________________
=======================================================================
Send completed form and payment to:
MicroFirm
P.O. Box 428
Alief, TX 77411
=======================================================================
- do not write below this line -
recd________ sent________ version_______ serial no.__________________
